home *** CD-ROM | disk | FTP | other *** search
- Path: inforamp.net!ts32-15
- From: rmorin@inforamp.net (Randy Charles Morin)
- Newsgroups: comp.lang.c++
- Subject: Re: Coding Standards
- Date: Sun, 24 Mar 96 04:40:42 GMT
- Organization: MiddleWorld SoftWare
- Message-ID: <4j2jot$svj@sam.inforamp.net>
- References: <4hj8ek$elu@sam.inforamp.net> <4hktar$5o2@galaxy.ucr.edu> <4hmqol$97j@abacus.abasoft.co.uk> <4hsg8r$pmm@sam.inforamp.net> <4i9o6j$p4l@daisy.pgh.wec.com> <4idskb$pc1@sam.inforamp.net> <314EBD08.43BC@virtus.com> <4io2i7$n9v@sam.inforamp.net> <4isu2t$opo@janus.pec.co.nz>
- NNTP-Posting-Host: ts32-15.tor.inforamp.net
- X-Newsreader: News Xpress Version 1.0 Beta #4
-
- In article <4isu2t$opo@janus.pec.co.nz>,
- JohnM@hypatia.pec.co.nz (John Marshall) wrote:
- >I think you have a hard time convincing anybody of this because it's
- >not true. It seems to me that "data hiding" has to do with the actual
- >*text* of clients' source code, and that recompilation is merely an
- >implementation detail.
- >If we had really defeated the purpose of data hiding, the statement
- >would be: "if your data's type changes, then you have to rewrite all the
- >clients". This is not the case when accessors are functions which just
- >happen to be inline.
- >Of course, in practice, all that recompilation during development is a
- >major pain. I guess that's why people put what are going to be inline
- >accessors in library.inc, and include library.inc in either library.cpp
- >or (for inlining) library.hpp, dependant on whether it's a "dev make" or
- >"production make" respectively. Certainly they're implementation -- they
- >don't *belong* directly in the header file.
- >Seems to me that the fundamental problem is that include files are
- >inherently broken compared to more automatic ways of managing the required
- >information. Alas.
-
- Great, so your code is object oriented, encapsulated and has data hiding. But
- your post compilation objects are not encapsulated and don't use data hiding.
- That means, that if your object data member's changes types, then you have to
- make an effort to conform other objects to your changes. If you don't have
- inline accessors, then you don't have a problem. Is this so hard to
- understand?
-
- Imagine you are a producing a commercial system for several large
- corporations. The large corporation use your hooks (sometimes inline
- accessors) to add functionality that is dependant on their particular business
- needs. After shipping version 1.0 with an object of type char (inline
- accessed), you ship the less buggy version 1.1 with the data type changed to
- an int. Now you have to coordinate your releases with the corporations. If
- you eliminate inline accessors, then you don't have that problem.
-
- When you talk about having to rewrite code because you defeated data hiding,
- you are limiting your scope to the problems encountered by a small development
- environment. This is not usually a problem when you are the only developer
- and you don't share code, but when you are sharing code with 100s of
- co-developers, you can't expect everybody to coordinate the changing of a data
- type. I hope I've convinced another.
-
-
- Agrivar
-
- aka Randy Charles Morin
- MiddleWorld SoftWare
- Canada: 1-800-363-3780
- Other: 905-279-2087
-